(12) INTERNATIONAL APPLICATION PUBLISHED UNOER THE PATENT COOPERATION TREATY (PCT) 



(19) World Intellectual Property Organization 

Int^ationai Bureau 

(43) International Publication Date 
25 April 2002 (25.04.2002) 




PCT 



iiiiiiiiiiiiiiiiiniiiiiiiiii 

(10) International Publication Number 

wo 02/33931 Al 



(51) International Patent Classification^: H04L 29/06 

(21) International Application Number: PCT/nOl/00902 

(22) International FiUng Date: 17 October 2001 (17.10.2001) 

(25) Filing Language: EngDsh 

(26) Publication Language: English 



(30) Priority Data: 

20002307 



18 October 2000 (18.10.2000) Fl 



(71) Applicant (for all designated States except USJt NOKIA 
CORPORATION [FOTI]; Keilalahdentie 4, FIN-Q2150 
Espoo(FI). 

(72) Inventors; and 

(75) Inventors/Applicants (for US onfy)x TOURUNEN, 
Ari [FI/FI]; Ldlitie 1 D 36, FIN-02230 Espoo (FI). 
KALLIOKULJU, Juha pi/FI]; Jokioistentie 5. 
FIN-3747P Vesilahti (FO- 

(74) Agent: KOLSTER OY AB; Iso Roobertinkatu 23, P.O. 
Box 148, FIN-00121 Helsinki (FI). 



(81) Designated States (national)i AE, AG, AL, AM, AT, AT 
\ (utility model), AU, AZ, BA, BB. BG, BR. BY, BZ, CA, 
CH, CN, CO, CR, CU, CZ, CZ (utility model), DE, DE 
(utility model), DK, DK (utility model), DM, DZ, EC, EE, 
EE (utility model), ES, FI, H (utility model), GB, GD, GE, 
GH, GM, HR, HU, ID, IL, IN. IS. JP. KE, KG. KP, KR, KZ, 
LC, LK, LR. LS, LT, LU. LV, MA, MD, MG, MK, MN. 
MW, MX. ^E, NO, NZ, PH, PL, FT. RO. RU, SD, SE, SG, 
SI, SK, SK (utility model). SL, TJ. TM, TR, IT, TZ, UA, 
UG, US, UZ. VN, YU, ZA, ZW. 

(84) Designated SXSkits (regional)-. ARIPO patent (GH, GM, 
KE, LS, MW. MZ, SD, SL, SZ, TZ, UG, ZW), Eurasian 
patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), European 
patent (AT, BE, CH, CY, DE, DK, ES. FI, FR, GB. GR, IE, 
rr. LU. MC, NL, FT, SE, TRX OAH patent (BF, BJ, CF, 
CG. a, CM, GA, GN, GQ, GW, ML, MR, NE. SN, TD, 
TG). 

Published: 

— with international search report . 

For two-letter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations" appearir^ at the begin- 
ning of each regular issue of the PCT Gazette. 



(54) Title: DEFINING HEADER FIELD COMPRESSION FOR DATA PACKET CONNECTION 



B 



ON 



O 



= C-SAP 



0 



PDCP 









Header 

cxympressor 

entity 


Header 

compressor 

entity 









RLCSAP 



(57) Abstract: A method of defining header field 
compression for a data packet connection and a 
header field compression system, in which a context 
for controlling the operation of a compressor and 
decompressor is defined as one parameter of the 
cotinection. A length is defined for a context 
identifier used in identifying data packet comiections 
for data transmission between the compressor and 
decompressor, said length defining the maximum 
number of dat^ packet connections traiismitted on one 
coimectioh. Each data packet connection is identified 
by its own context identifier The parameters of 
the connection are defined in such a manner that 
at least the number of header fields of data packet 
connections allowed by the defined context identifier 
length can be compressed despite the fact that the 
number of data packet connections allowed by said 
context identifier length is exceeded. 
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bearer, and the user of the terminal wants to form one more simultaneous 
data flow. Because a maximum number of context identifiers is already in use, 
a context identifier cannot be defined for the new data flow. Then, if the new 
data flow needs to be transmitted compressed, a data flow context already in 
5 use will be defined for it. This means that two compressed data connections 
having the same context identifier are established, which the decompressor is 
unable to distinguish from each other, and an error situation arises in the 
entire compression system. Because the current practices of ROHC do not 
define the action to be taken on a new "extra" data flow, the problem described 

10 above occurs alvrays vAien a radio bearer uses the maximum number of data 
connections allowed by the context identifier CID and the user of the terminal 
tries to open a new data flow. Further, a terminal used in some situations, for 
instance when applying ROHC to mobile systems, may set its own internal 
limitations due to memory space, for instance, on simuRaneous data 

15 connections, and these limitations may . be stricter than what ROHC would 
require. . 

BRIEF DESCRIPTION OF THE INVENTION 

It is thus an object of the invention to develop a metiiod and an 
apparatus implementing the method so as to reduce the above-mentioned 

20 drawbad^s. The object of the invention is achieved by a method and system, 
vMch are characterized by what is stated in the independent claims. Preferred 
embodiments of the invention are set forth in the dependent claims. 

The invention is based on the idea that despite exceeding the 
, number of data packet connections allowed by the context identifier length, the 

25 radio bearer parameters are defined in such a manner that at least the number 
of data packet connection header fields allowed by the defined context 
identifier length can be compressed. According to a preferred embodiment of 
the fnvenfion, this can be implemented by allocating at least one value from 
the length of the defined context identifier for an uncompressed data flow. 

30 According to a second preferred embodiment of the invention, in which 
compression is controlled by the convergence protocol layer of the mobile 
system, the mobile system is directed to re-define the radio bearer parameters 
in such a manner that the new value of the context identifier length enables 
the compression of the header fields, of all data packet connections, if the 

35 number of data; packet connections ajiowed by the original context identifier 
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length is exceeded. According to a further prefenred embodiment of the 
invention, in response to exceeding the number of data packet connections 
allowed by the maximum value of the context identifier length, the 
convergence protocol layer is directed to define for the data packet 
5 connections several link-level connections, to which the data packet 
connections are allocated. 

The method and system of the invention provide the advantage that 
at least as many data connections being transmitted on the radio bearer as 
allowed by the length of the context identifier field at its maximum can in all 

10 situations be compressed. Further, the procedure of the invention provides the 
advantage that discontinuation of compression for the data connections that 
are transmitted compressed is avoided. A yet further advantage of the 
invention is that it enables applying header field compression to data 
connections in the most efficient manner possible, which is advantageous for 

15 the efficient utilisation of radio resources. 

BRIEF DESCRIPTION OF THE FIGURES 

In the following, the invention will be described in greater detail by 
means of preferred embodiments and with reference to the appended 
drawings in which 

20 Figure 1 is a block diagram of transitions between different 

compression levels of ROHC, 

Figure 2 is a block dlagranri of transitions between different 
operational modes of ROHC, 

Figure 3 is a block diagram of a simplified structure of the UMTS 

25 system. 

Figures 4a and 4b show protocol stacks of the UMTS packet data 
service for control signalling and transmitting user data, 

Figures 5a and 5b show operational models of the PDCP layer, and 
Figure 6 shows defining data packet identifiers according to an 
30 embodiment of the invention. 

. DETAILED DESCRIPTION OF THE INVENTION 

In the following, the implementation of the header field compression 
method ROHC in question is described for the parts essential for the invention. 
For a more detailed description of the compression method in question, 



wo 02/33931 



PCT/FIOl/00902 



5 

reference is made to a yet unfinished Internet draft "Robust Header 
Compression (ROHC)", version 04, 11 October 2000. 

In different compression methods, a context Is typically defined for 
both a compressor and a decompressor, the context being a state which the 
5 compressor uses to compress a header field to be transmitted and the 
decompressor uses to decompress a received header field. Typically, the 
context comprises an uncompressed version of the previous header 'field 
transmitted (compressor) or received (decompressor) over a data transfer 
connection. In addition, the context can comprise infonnation identifying a data 
1 0 packet flow, such as sequence numbers or time stamps of data packets. Thus, 
the context typically comprises both static infonnation. which remains the 
same for the entire data packet flow, and dynamic infonnation, which changes 
during the data packet flow, but often does It accorcling to a defined pattern. 

ROHC uses three compression levels In such a manner that the 

16 compression is started on the lowest level and continues gradually to the 
higher levels. The basic principle Is that compression is always perfonned on 
the highest possible level. In such a manner, however, that the compressor 
has sufficient certainty of the fact that the decompressor has enough 
infonnation to perfbnn decompression on. the level in question. Factors 

20 affecting ttie move between different compression levels are variation In 
consecutive header fields, positive and negative acknowledgements received 
from the decompressor, and when ttiere are no acknowledgements, the 
expiration of specific sequential counters. It is possible to move 
conespondingly to a lower level fi-om a higher compression level. 

2^ The compression levels ROHC uses in connection with IP (Intemet 

Protocol). UDP (User Datagram Protocol) and RTP (Real-Time Protocol) 
protocols are initiation/refresh (IR), first order (FO), and second order (SO), 
and teansitions between these levels are described in the diagram of Figure 1.' 
The IR level is used to create the context for the decompressor or to recover 

30 from an enror situation. The compressor moves to tiie IR level when header 
field compression is started, requested by the decompressor, or when an 
update timer expires. On the .IR level, the compressor sends IR header fields 
In ah uncompressed fonnat The compressor tries to move to a higher level 
when It Is certain that tiie decompressor has received tiie update infonnation. 

36 The FO level Is used to Infonn tiie recipient of in^egularities in ttie 

header fields of tiie data packet flow. After the IR level, the compressor 
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operates on the FO level in a situation where the header fields do not form a 
uniform pattern (in other words, consecutive header fields change randomly in 
such a manner that the changes cannot be predicted) or the compressor 
cannot be certain that the decompressor has received the parameters defining 
5 the unifonn pattem of the header fields. This is a typical situation when 
' transmitting speech, for instance, is started, esjDecially during the first speech 
bursts. On the FO level, the compressor sends compressed FO header fields. 
The compressor again tries to move to a higher level if the header fields form 
a uniform pattem and It is certain that the decompressor has received the 
10 parameters defining the unifonn pattem. The FO-level data packets comprise 
typically context update Information, which means that a successful 
decompression also requires a successful transmission of consecutive FO 
header fields. Thus, the success of the decompression process is sensitive to 
lost or damiaged FO-level packets. 
15 On the SO level, compression is optimal. The header fields form a 

uniform pattem which the compressor depicts with compressed SO header 
fields which, In practice, are sequence numbers of the data packets. 
Information is transmitted already on the FO level to the decompressor on 
parameters defining the uniform pattem of the header fields, and on the basis 
20 of the parameters and the received sequence number, the decompressor can 
extrapolate the original header fields. Because the data packets sent on the 
SO level are, in practice, independent of each other, the error sensitivity of 
decompression is also low. When the header fields no longer fomi a uniform 
pattem, the compressor moves back to the FQ level. 
2f5 Decompression also has three levels which are bound to the 

context definition of the decompressor. The decompressor always starts its 
operation from the lowest level when no-context has yet been defined (No 
Context). The decompressor has then not yet decompressed any data 
packets. When the decompressor has decompressed the first data packet 
30 which comprises both static and dynamic context information, it can move over 
the middle level (Static Context) straight to the top level (Full Context). As a 
result of several error situations on the top level, the decompressor moves to 
the middle level, but typically even one successfully decompressed data 
packet returns the decorripressor to the top leve^ 
35 In addition to different compression levels, ROHC has three 

difierent operational modes: unidirectional mode (U mode), bi-directional 



wo 02/33931 



PCT/FIOl/00902 



optimistic mode (O mode), and bl-dlrectional reliable mode (R mode), which 
are shown in the diagram of Figure 2. According to Figure 2, each 
compression level (IR, FO, SO) described above functions in each mode, but 
each mode functions In its own way on eadi level and also makes decisions 
5 on transitions between levels in its own way. The selection of the mode for 
each compression situation depends on the parameters of the used data 
transfer connection, such as the possibility to use a return channel, error 
probabilities and distribution, effects of variation in the size of the header 
fields. 

10 In the unidirectional mode, data packets are transmitted from 

compressor to decompressor only, so the U mode of ROHC is useful in 
situations vi/here the use of a return channel is not possible or desirable. In the 
U mode, transitions between different compression levels are made as a result 
of the expiration of oerlain sequential counters or on the basis of variation In 

15 the header field pattems. Because no return channel Is used, compression In 
. the U mode is less efficient and the disappeiSrance of data packets on the 
transmission path more probable than in either of the bi-directional modes. 
Using ROHC is always started in the U mode and transition to either of the bi- 
directional modes can take place when the decompressor has received at 

20 least one packet and as a response to the packet, the decompressor indicates 
that a mode dhange is necessary. 

The bi-directional optimistic mode is similar to the unidirectional 
mode with the exception that in the O mode, a retum channel is used to 
correct error situations and to acknowledge significant context updates from 

25 the decompressor to the compressor. Sequential updates are not made in the 
O mode. The O mode is preferably suited for connectk>ns vyhich require 
optimal compression efficiency with a small retum channel traffic. The O mode 
provides a reasonably reliable data packet transfer, in which the 
synchronisation between the compressor and decompressor can typically be 

30 maintained well and data packets are seldom lost and if they are, In negligible 
numbers. At very high bit error rates, data packets cari, however, be lost on 
the transmission path. \ .. 

The bi-directional reliable mode differs clearly firom the above- 
mentioned hnodes. The R nnode uses a return channel to acknowledge all 

35 conte)ct updates, also to acknowledge sequence number updates. Thus in the 
R mode, data packets can nearly entirely reliably be transmitted between the 
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compressor and decompressor. Compressing header fields cannot cause the 
disappearance of data packets in the R mode. A drawback of the R mode is 
that the size of the header field is in some cases slightly larger than in the 
above-mentioned modes and that the return channel traffic increases 
5 considerably. 

The three operational modes and three compression levels of 
ROHC fomn different operating situations for the compression of the header 
fields, each situation requiring the definition of the operation of the compressor 
and decompressor and the transmission of packets between them. ROHG 
10 uses different packets in different operating situations. At the moment, six 
different data packet types are defined for ROHC, four of which are used for 
transmission from the compressor to the decompressor and two as return 
channel data packets from the decompressor to the compressor. The number 
of used datei packet types may change in the future, but alt data packet types 
15 are characterized in that a context identifier CID defining the context used at 
each time is attached to each data packet before sending the packet to the 
transmission path. 

The length of the context identifier CID is negotiated separately for 
each radio bearer by the compressor and decompressor. According to the 
20 ROHC definitions, the lower protocol layer (link layer) used at each time must 
provide a mechanism for the negotiation of the parameters, such as the length 
of the context identifier, used in header field compression. The parameters are 
negotiated before starting the compression and, In this connection, the length 
of the context identifier of the data packet flow can, according to prior art, be 
25 defined to be 0, 8 or 16 bits. On one logical data trsinsfer channel, it is possible 
- to transmit simultaneously several data packet flows whose contexts are 
identified and distinguished from each other by means of the context identifier 
CID. If only ohe data packet fiow is transmitted on the channel, which Is typical 
of different VoIP applications (Voice over IP), for instance, the length of the 
30 context Identifier CID is made "small", i.e. given the value 0. However, evi9n at 
this time it is possible by means of internal ROHC mechanisms to distinguish a 
maximum of 16 sinriultaneous data flows frond each other, i.e. 15 new data 
connections can always be opened in addition to the original data flow, even 
though the length of the context identifier CID was defined to zero. This is 
35 implemented in such a manner that the first data conriection is always 
transmitted without any context identifier and to the folldwing data 
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connections, one byte is attached, whose first four bits indicate that this is a 
context identifier and the following four bits indicate the actual context identifier 
value. If, when defining the radio bearer, it is obvious that several data packet 
flows will be transmitted on the same channel, a large value, i.e. either 1 or 2 
5 bytes (8 or 16 bits), is preferably defined as the length of the context identifier 
depending on the application, data transmission protocol and channel 
conditions used on the radio bearer. 

One telecommunications system, to which the header field 
compression method according to the ROHC specifications is to be applied, is 
10 a third-generation mobile system, also known as UMTS (Universal Mobile 
Telecommunication System) and IMT-2000 (International Mobile Telephone 
System). In the following, the structure of the UMTS system is described in a 
simplified manner on the basis of Figure 3. 

Figure 3 only contains the blocks essential for explaining the 
15 invention, but it is obvious to a person skilled in the art that a conventional 
mobile telephone system also comprises other functions and structures, which 
need not be described in greater detail herein. The main parts of a mobile 
telephone system are a core network CN, a UMTS mobile telephone system 
terrestrial radio access network UTRAN, which form the fixed network of the 
20 mobile telephone system, and a mobile station or user equipment UE. The 
interface between CN and UTRAN is referred to as lu and the air interface 
between UTRAN and UE is refenred to as Uu. 

UTRAN typically comprises several radio network subsystems RNS, 
the interface between the RNSs being refened to as fur (not shown). RNS 
25 comprises a radio network controller RNC. and one or more base stations BS, 
also referred to as nodes B. The interface between RNC and BS is refenred to 
as lub. The base station BS typically takes care of radio path implementation 
arid the radio network controller RNC manages at least the following: 
management of radio resources, control of handover between cells, power 
30 adjustment, timing and synchronization, paging the subscriber terminal. 

The core networi< CN is made up of an infrastructure belonging to a 
mobile telephone system and external to UTRAN. In the core network, a 
mobile switching centre / visitor location register 3G-MSCA^LR is connected to 
a home location register HLR and preferably also to a service control point 
35 SCP of an intelligent network. The home location register HLR and the visitor 
location register A/LR comprise information on mobile subscribers: the home 
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location register HLR comprises information on all subscribers in a mobile 
network arid the services they subscribe to, and the visitor location register 
VLR comprises information on mobile stations visiting the area of a certain 
mobile switching centre MSG. A connection to a serving node of a packet radio 
5 system 3G-SGSN (Sen/ing GPRS Support Node) is fornied through an 
interface Gs' and to a fixed telephone network PSTN/ISDN through a gateway 
mobile switching centre GMSC (not shown). A connection from the serving 
node 3G-SGSN to external data networks PDN is fomied through an interface 
Gn to a gateway node GGSN (Gateway GPRS Support Node) which has a 

10 further connection to the extemal data networks PDN. The connection from 
both the%iobile switching centre 3G-MSCA/LR and the serving node 3G- 
SGSN to the radio networi^ UTRAN (UMTS Tenrestrial Radio Access Networic) 
is set up through the interface lu. it should be noted that the UMTS system is 
designed in such a manner that the core networic CN can be identical to the 

1 5 core networic of a GSM system, for instance, in which case there is no need to 
rebuild the entire network infrastructure. 

The UMTS system also comprises a packet radio system which is 
to a large extent implemented according to a GPRS system connected to a 
GSM network, which explains the references to a GPRS system in the names 

20 of the network elements. The UMTS packet radio system can comprise 
several gateway and serving nodes, and several serving nodes 3G-SGSN are 
typically connected to one gateway node 3G-GGSN. Both nodes 3G-SGSN 
and 3G-GGSN function as routers supporting the mobility of a mobile station, 
which routers control the mobile system and route data packets to mobile 

25 stations riegardless of their location and the used protocol. The serving node 
36-SGSN is in contact witii a mobile station UE through the. radio network 
UTRAN. A task of the serving node 3G-SGSN is to detect mobile stations 
capable of packet radio connections in its service area, to transmit and receive 
data packets from said mobile stations and to track the location of the mobile 

30 stations iri its service area. Further, the serving node 3G-SGSN is in contact 
with the mobile switching centre 3G-MSC and the visitor location register VLR 
through the signalling interface Gs' and with the hotne location register HLR 
through the interface Gr. Records related to packet radio services and 
comprising subscriber-specific packet data protocol contents are also stored in 

35 the home location register HLR: 
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The gateway node 3G-GGSN acts as a gateway between the 
UMTS network packet radio system and the external data network PDN 
(Packet Data Network). External data networks include the UMTS or GPRS 
network of a second network operator, the Internet, an X.25 network or a 
5 private local area network. The gateway node 3G-GGSN is in contact with said 
data networks through the interface Gi, Data packets being transmitted 
between the gateway node 3G-GGSN and the serving node 3G-SGSN are 
always encapsulated according to the gateway tunnelling protocol GTP. The 
gateway node 3G-GGSN also contains PDP (Packet Data Protocol) addresses 

10 of the mobile stations and routing information, i.e. 3G-SGSN addresses. The 
routing information Is thus used to link the data packets between the external 
data network and the serving node 3G-SGSN. The network between the 
gateway node 3G-6GSN and the serving node 3G-SGSN employs an IP 
protocol, preferably the IPv6 (Internet Protocol, version 6). 

15 Figures 4a and 4b show UMTS protocol stacks used for control 

signalling (control plane) and user data transmission (user plane) in a packet 
radio service of the UMTS system. Figure 4a shows the protocol stack used 
for control signalling between a mobile station MS and the core network CN. 
MobiKity management MM of the mobile station MS, call control CC and 

20 session management SM are signalled on the highest protocol layers between 
the mobile station MS and the core network CN in such a manner that the 
base stations BS and the radio network controller RNC located In between are 
transparent to this signalling. Radio resource management of radio links 
between mobile stations MS and base stations EfS is managed by a radip 

25 resource management system RRM which transmits control data from a radio 
network controller RNC to base stations BS. These functions related to the 
general managemerit of a mobile system form a group called cora network 
protocols (CN protocols), also known as Non-Access Stratum. 
Correspondingly, the signalling related to radio network control between a 

30 mobile station MS, a base station BS and a radio network controller RNC is 
done on protocol layers called radio access network protocols (RAN 
, protocols), i.e. Access Stratum. These include transfer protocols on the lowest 
level and the control signalling transmitted by the transfer protocols is 
transferred to the higher levels for further processing; The most essential of 

35 the higher Acces$ Stratum layers is the radio resource control protocol RRC 
which is responsible for establishing, configuring, maintaining and releasing 
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radio links between the mobile station MS and the radio network UTRAN and 
for transmitting control information from the core network CN and the radio 
network RAN to the mobile stations MS. In addition, the radio resource control 
protocol RRC is responsible for allocating enough capacity for the radio bearer 
5 according to the instructiohs of the radio resource nianagement system RRM 
in application-based capacity allocation, for instance. 

A protocol stack as shown In Figure 4b is used in transmitting 
UMTS packet-switched uiser data. On the interface Uu between the radio 
network UTRAN and a mobile station MS, the lower-level data transmission on 
10 a physical layer is performed according to a WCDMA or TD-CDMA protocol. A 
MAC layer above the physical layer transmits data packets between the 
physical layer and an RLC layer and the RLC layer handles the logical 
management of the radio links of different radio bearers. The RLC functions 
comprise for instance segmenting the user data (RLC-SDU) being transmitted 
15 into one or more RLC data packets RLC-RDU. IP header fields in data packets 
(PDCP-PDU) of a PDCP layer above RLC can optionally be compressed. After 
this, PDCP-PDUs are fonvarded to RLC and they correspond to one RLC- 
SDU. The user data and the RLC-SDUs are segmented and transmitted in 
RLC frames, to which address and verification information essential for data 
20 transmission is added. The RLC layer also takes care of re-transmission of 
damaged frames. The serving node 3G-SGSN manages the routing of the 
data packets coming from the mobile station MS through the radio network 
RAN on to the correct gateway node 3G-GGSN. This connection uses the 
tunnelling protocol GTP which encapsulates and tunnels all user data and 
25 signalling transmitted through the core network. The GTP protocol runs on top 
of the iP Used by the core network. 

; Figure 5a shows an functional model of the PDCP layer, in which 
one PDCP entity is defined for each radio bearer. Since in the present 
systems, an individual PDP context is defined for each radio bearer, one 
30 PDCP entity is also defined for each PDP context, and a certain RLC entity is 
defined for each PDCP entity on the RLC layer. As stated above, the PDCP 
layer can in principle also be functionally implemented in such a manner that 
several PDP contexts are multiplexed on the PDCP layer, in which case on the 
RLC layer below the PDCP layer, one RLC entity receives data packets from 
35 several radio bearers at the same time. . 
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Figure 6b Illustrates a Situation, in which a PDCP entity receives 
data paclcets through one radio bearer from two different applications, A and 
B. The data flows in the radio bearer are distinguished from each other on the 
basis of IP header fields before the header field compressor in the PDCP 
5 entity, after which the data flows are taken to be compressed. The compressor 
distinguishes the data flows from each other by defining them separate context 
identifiers, by means of which the decompressor of the receiver can again 
distinguish the data flows from each other and decompress them. To illustrate 
this, Figure 5b shows the compressor entity as two separate boxes, but in 
10 practice, there are two compression contexts within the same compression 
entity. The compressed data flows are, however, transmitted over the same 
RLC connection. 

Each PDCP entity can use one or more header field compression 
algorithms or not use any. Several PDCP entities can also use the same 

15 algorithm. The radio resource controller RRC negotiates a suitable algorithm 
for each PDCP entity as well as parameters controlling the algoritiim and then 
advises the selected algorithm and parameters to the PDCP layer through a 
PDCP-C-SAP point (PDCP Control Sen/ice Access Point). The used 
compression method depends on the network-level protocol type used on the 

20 connection, the type being indicated to the radio resource controller when the 
PDP context is activated. 

In the(, UMTS system, header field compression of data packets 
being transmitted and decompression of received data packets are thus done 

on the convergence protocol layer PDCP. The tasks of the PDCP layer include 
25 functions related to improving channel efTiciency, yvhrch are typically based on 
different optimization mettiods, such as utilisation of compression algoritiims 
of data packet header fields. Since today the network-level protocols planned 
for UMTS are IP protocols, the compression algorithms used are tiiose 
standardized by IETF (Internet Engineering Task Force). Thus, the ROHC 
30 compression method is especially well-suited for the UMTS system. The 
PDCP layer of the terminal typically supports several header field compression 
methods so as to allow connection establishment with as many network-level 
protocol types as possible. . 

. When applying -ROHC to tiie cpnvei^ence protocol layer of UMTS, 

35 both the transmitting PDCP and the receiving PDCP comprise a compressor- 
decompressorrpair for compressing the data packets being ti^nsmitted and 
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decompressing the received data packets. Tlie convergence protocol layer 
PDCP provides the compression method ROHC a miechanism for negotiating 
the length of the context identifier for each radio bearer. In practice, the 
mechanism is implemented in such a manner that the PDCP layer transmits 
5 the messages of the compressor and decompressor on to RRC and the actual 
negotiation is done by RRC signalling. To be able to utilise the radio resources 
as efficiently as possible, the length of the context identifier CID is preferably 
defined as zero for the radio bearer. 

' if the length of the context identifier CID defined for the radio bearer 

10 is "small", i.e. zero bytes, and all possible 16 data connections are in use, and 
if the user of the terminal wants to establish one more simultaneous data flow 
for a radio bearer having such a definition, a problem situation occurs, since 
17 simultaneous data flows cannot be distinguished from each other with a 
"small" context Identifier. Because a new data flow cannot be identified by its 

15 own context identifier according to ROHC specifications, a context identifier of 
an existing data flow will be defined for it. In such a case, two data flows 
having the same context identifier are transmitted sinriultaneousiy, which 
results in an error situation in the decompressor, because the decompressor 
can no longer distinguish the data connections from each other. A 

20 corresponding problem also arises with any other defined CID length value, 
when the radio bearer uses the maximum number of data connections defined 
for the length of the context identifier CID, and the user of the terminal tries to 
open a new data fiow. Transmitting several data flows oyer a radio interface 
without header field compression leads to an inoptimal utilisation of radio 

25 resources; which is a hindrance to an efficient use of the entire mobile system. 

^ ' problems described above can, however, now be reduced with 
the procedure of the invention, in which the parameters of the radio bearer are 
defined in such a mariner that at least the number of data packet connection 
header fields allowed by the length of the defined context identifier can be 

30 compress;ed despite the fact that the number of data packet connections 
allowed by said context identifier length is exceeded. This way, it Is possible to 
ensure that for instance when the length of the radio bearer context identifier is 
set at zero and the user of the terminal wants to establish a 17^ simultaneous 
data flow for the radio bearer, at least the original 16, preferably all 17. data 

35 flows can be transmitted using ROHC. Correspondingly, with any other defined 
CID length value, when the radio beiarer uses the maximum nurriber of data 
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• connections defined for the length of the context identifier CID, and the user of 
the temninal tries to open a new data flow, it is possible to ensure that at least 
a number conesponding to the original number of data connections, preferably 
all data flows, can be transmitted using ROHC. 
5 According to a first embodinrient of the Invention^ the definition 

described above can be performed by means of ROHC so that the ROHC 
algorithm is defined in such a manner that at least one value, preferably the 
last one. of the length of the context identifier CID, i.e. CID space, negotiated 
for each radio bearer is always reserved for an uncompressed data flow. Thus, 

10 it is possible to ensure that the data connections already in use can be - 
transmitted compressed and, at the same time, a new data connection can be 
established without compression. The ROHC algorithm can, for instance, be 
defined on the basis of the negotiation between the compressor and 
decompressor in such a manner that If the length of the context identifier field 

15 is set to zero, the first 15 data flows are. compressed, and If the user of the 
temilnal tries to fomn a new (16*) data flow, It and any simultaneous data flows 
fomned after it are transmitted uncompressed to the reviver. A CID field is 
attached to the uncompressed data padcets to ihfomn the receiver that their 
header fields have not been compressed and they should, thus, be directed 

20 past the decompressor. It is also possible to reserve for uncompressed data 
flows several values of the CID space of the context Identifier field negotiated 
for the radio bearer. 

According to a second embodiment of the invention, the 
convergence protocol layer PDCP monltoTS the number of data connections 

25 and If the number of allowed data connections Is exceeded, the PDCP layer 
infonns the radio resources control protocol RRC of this, which then perfomis 
radio bearer reconfiguration during which the radio bearer parameters, 
especially tiie length of the context identifier, are re-defined so that the header 
fields of each data flow can be compressed according to ROHC, For Instance. 

30 if the length of the radio bearer context identifier is set to zero and the PDCP 
layer detects 17 or more simultaneous data flows, the radio bearer is re- 
conflgured. whereby the maximum value of the context identifier field is 
defined to be larger than zero. This requires that a new functionality is added 
to the PDCP layer to monitor the number of data connections of each radio 

35 bearer. If the number of data connections on a radio bearer corresponds to the 
maximurh value of the context Identifier length, and a new data connection is 
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being established, PDCP Informs RRC as described above. It is also possible 
that due to the limited properties of the terminal, for instance, the number of 
simultaneous data connections is through RRC signalling set to four data 
flows, for instance. It is then necessary that the PDCP layer can monitor the 
5 number of simultaneous data connections as described above, because the 
ROHC mechanisms do not affect a situation in which the highest number of 
simultaneous data connections is smaller than the maximum value of the 
context identifier field. 

-The first and second embodiment described above can, according 

10 to a preferred embodiment, be used by means of the PDCP layer in such a 
manner that the PDCP layer monitors according to said second embodiment 
the number of data connections on a radio bearer and when necessary 
defines according to said first embodiment that header field compression is 
not performed to the extra data connections exceeding the number of data 

15 connections allowed by the maximum context identifier value. This ensures 
that at least the original data flows can be transmitted optimally compressed. 
In such a case, if the length of the context identifier of the radio bearer is 
defined at zero, for instance, and the PDCP layer detects 17 simultaneous 
data flows, said last (17*^) flow Is transmitted without header field compression, 

20 and said functionality of the PDCP layer directs the new data flow past the 
compressor. According to a preferred embodiment, said functionality of the 
PDCP layer can also select the data flows which are compressed, in which 
case the data flow being directed past the compressor is not automatically the 
data flow formed last. 

25 -According to a third embodiment, the UMTS entity (e.g. session 

management protocol SM) which, when a data connection is being 
established, decides, to which radio bearer the new data flovys belong, is, 
when the data connection is being established, informed of the limitations 
caused by the niaximurti value of the context identifier to the number of 

3d sinnultaneous date connections, especially when the length of the radio bearer 
context identifier is set at zero. If 16 data flows are then in use and a need for 
17 or more simultaneous data flows is detected, a new "extra" data flow can 
be defined its own radio bearer or the first radio bearer is ren^nfigured and 
the length of the context identifier field is given a larger value than zero. In 

35 both cases, the header fields of each data flow can be compressed according 
to ROHC. In this enibbdiment, too, one must especially take into consideration 
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a Situation, in which, due to the limited properties of the terminal, the highest 
number of simultaneous data connections is only four data flows, for instance. 
In such a case, It Is necessary that the entity controlling the establishment of 
the data connection is able to monitor the number of simultaneous data 
5 connections as described above. 

According to a fourth embodiment, packet identifiers (PID) in the 
data packet structure of the PDCP layer are used to indicate the changes 
needed in the length of the context identifier. On the PDCP layer, the different 
compression methods are indicated and distinguished from each other by 

10 means of packet identifiers PID attached to the data packets PDU. For each 
PDCP entity, a table is created for the values of the packet identifier PID, in 
which different compression algorithms are matched with different data 
packets, and the value of the packet identifier PID is detennined as a 
combination of these. If no compression algorithm is used, the packet identifier 

15 PID obtains the. value zero. PID values are consecutively defined fbr each 
compression algorithm and its combination with different data packet types in 
such a manner that the PID values of each compression algorithm- start from 
n+1, wherein n is the last PID value defined for the previous compression 
algorithm. The order of compression algorithms is detennined in negotiation 

20 with the radio resource controller RRC. On the basis of the PID value table, 
the PDCP entities at both ends of the packet data connection can identify the 
compression algorithms of data packets being sent and received. 

These PID values can, in this embodiment of the invention, be 
utilised in such a manner that three PID values are allocated for different 

25 context Identifier field values (0, 1 or 2 bytes) of ROHC according to the table 
shown in Figure 6. AHematively, two PID values can be allocated to represent 
the Cip space values "small" (0 bytes) and 'large" (1 or 2 bytes). Then with a 
"large" CID space value, the CID field extension bits can be used to indicate in 
more detail whether this concerns an 8- or 16-bit CID field. Now, if the context 

30 identifier length of the radio bearer is set at zero and the PDCP layer detects 
17 simultaneous data flows, a change in the CID field length can be indicated 
to the receiving PDCP entity by means of these PID values. The PID values 
are preferably transrnitted until the radio bearer is re-configured or the number 
of data connections goes back to 16. 

35 According to a fitth embodiment, the length of the CID field is not re- 

defined, even though the maximum value of the CID space was exceeded, but 
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a separate RLC connection can be established for different data connections. 
This can be implemented in such a manner that when the maximum value of 
the CID space is exceeded, each new data connection gets a separate RLQ 
connection whose CID field length is preferably zero. Altematlvely, a separate 
5 RLC connection, whose CID field length is set to zero, can be defined for each 
data flow. Further, the data flows can be distributed to two RLC connections in 
a situation where 32 data flows are in use. in which case the data flows can be 
distributed to two RLC connections whose CID field lengths can preferably be 
kept at zero. Then the PDCP layer specifications should be modified to allow 
10 one PDCP entity to use several RLC connections simultaneously. For the 
utilisation of radio resources, this embodiment is optimal, because each 
simultaneous data flow can be transmitted without a CID field (CID length = 0), 
in which case the payload proportion of the transmitted data can be 
maximized. 

15 According to a sixth embodiment simultaneous data connections 

exceeding the defined maximum value of the context Identifier are not 
accepted for transmission. If the context Identifier length of the radio bearer 
has been set to zero, for Instance, and there are 16 data flows in use, and an 
attempt is made to fonn a I?**' simultaneous data flow, the PDCP layer and/or 

20 compressor will not accept said 17*^ data connection for establishment, and its 
data packets will be rejected. 

This way, the procedure of the invention ensures that in all 
situations it is possible to compress at least as many data connections 
transmitted on the radio bearer as allowed by the maximum length of the 

25 context identifier field defined for the radio bearer. Further, the discontinuation 
of the corhpression of data connections which ane transmitted compressed is 
avoided by means of the procedure of the Invention. The procedure of the 
invention enables applying header field compression to data conneictions in 
the most efficient manner possible, which is advantageous for ah efficient 

30 utilisation of radio resources. . 

The procedure of the invention is above described using the UMTS 
system as an example. Header field compression according to ROHC is, 
however, not bound to the UMTS system, but can preferably be applied to any 
telecommunications system transmitting IP data packets. The procedure of th 

35 Invention can preferably be applied for instance to furtiier development 
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projects of second-generation mobile systems, sucli as GERAN (GSIVl Edge 
Radio Access Netwot1(). 

It is obvious to a person sl(illed in the art that while technology 
advances, the basic idea of the invention can be implemented in mariy 
different ways. The invention and ite embodinfients are thus not restricted to 
the examples described above, but can vary within the scope of the claims. 
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CLAIMS 

1 . A method of defining header field compression for a data pacl<et 
connection, in which method a context is defined for a compressor and 
decompressor as one parameter of the connection for controlling the operation 

5 of said compressor and decompressor, a length is defined for a context 
identifier used in identifying data packet connections on data transmission 
between the compressor and decompressor, said length defining the 
maximum number of compressed data packet connections transmitted on one 
connection, and each data packet connection is identified by its own context 

10 identifier, c h a racterlzed by 

defining the parameters of ttie connection in such a manner that at 
least the number of header fields of data packet connections allowed by the 
length of the defined context identifier can be compressed despite the fact that 
the number of data packet connections allowed by said context identifier 

15 length Is exceeded. 

2. A method as claimed in claim 1 , c h a r a c t e r I z e d by 
reserving at least one value of the length of the defined context 

identifier for an uncompressed data flow. 

3. A method as claimed in claim 1 or 2, in which method 
20 compression is controlled by a convergence protocol layer of a mobile system, 

characterized by 

directing the mobile system^ in response to exceeding the number 
of data packet connections allowed by the context identifier length, to re-define 
the paranrieters of a radio bearer in such a manner that the new value of the 
25 context identifier length enables the compression of the header fields of all 
data packet connections, 

4. A method as claimed in claim 3, c h a r a c te r i ze d by 
using values defined for data packet identifiers of the convergence 

protocol layer to define the new value for the context identifier length. 
30 5. A method as claimed in claim 1 or 2, in which method 

compreission Is controlled by the convergence protocol layer of the mobile 
system, characterized. by 

signalling tiie maximum number of simultaneous data packet 
connections defined for each radio bearer to the mobile system entity which, 
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when establishing a new data packet connection, decides which radio bearer it 
will be associated with, and 

directing the mobile system, in response to exceeding the number 
of data packet connections allowed by the context identifier lengtti, to re-define 
5 the radio bearer parameters in such a manner that the new value of the 
context identifier length enables the compression of the header fields of all 
data packet connections. 

6. A method as claimed in claim 1 and 2, in which method 
compression is controlled by the convergence protocol layer of the mobile 

10 system, characterized by 

signalling the maximum number of simultaneous data packet 
connections defined for each radio bearer to the mobile system entity which, 
when establishing a new data packet connection, decides which radio bearer it 
will be associated with, and 

15 directing the mobile system, in response to exceeding the number 

of data packet connections allowed by the maximum value of the context 
identifier length, to define a new radio k>earer for the extra data packet 
connections. 

7. A method as claimed in claim 1 and 2, in which method 
20 compression is controlled by the convergence protocol layer of the mobile 

system, characterized by 

directing the convergence protocol layer or the compressor in it, in 
response to exceeding the number of data packet connections allowed by the 
maximum value of the contexl Jdentifler length, to transmit the extra data 
25 packet connections witiiout header field compression. 

8. Amethodasclaimed in claim 7, characterized by 
attaching to said extra data packet cx)nnections an identifier, on the 

basis of which the data packets are received without decompression. 

9. A method as claimed in claims 1 or 2, in which method 
30 compression is controlled by the convergence protocol layer of the mobile 

system, c h a r a c t e r i z e d by 

directing the convergence protocol layer, in response to exceeding 
the number of data packet connections allowed by the maximum value of the 
context identifier length, to define for the data packet connections several link- 
35 level connections to which the data packet connections are alloca^^ 
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10. A method as claimed in claims 1 or 2, in which method 
compression is controlled by the convergence protocol layer of the mobile 
system, c h a r a c t e r i ze d by 

directing the convergence protocol layer, in response to exceeding 
5 the number of data paclcet connections allowed by the maximum value of the 
context identifier length, to reject the extra data packet connections. 

11. A method as claimed in any one of claims 3 to 10, 
c h a r a c t e r i z e d in that 

the terminal limits the number of simultaneous data packet 
10 connections to be smaller than the number of data packet connections allowed 
by the maximum value of the context identifier length. 

12. A header field compression system comprising a compressor 
and decompressor, a context being arranged to be defined for tiie data packet 
connection between them as one parameter of tiie connection, the context 

15 controlling the operation of said compressor and decompressor and 
comprising a context identifier to identify the data packet connections, a length 
being arranged to be defined for the context identifier for data transmission 
between the compressor and decompressor, said length defining the 
maximum number of compressed data packet connections transmitted on one 

20 connection, and said data packet connections being arranged to be identified 
by a context identifier, c h a r a c t e r I z e d in that 

the parameters of the connection are arranged to be defined in 
such a manner that at least the number of header fields of data packet 
connections allowed by the defined context identifier length can be 

25 compressed despite the fact that the nuniber of data packet connections 
allowed by said context identifier length is exceeded. 

13. A system as claimed in claim 12, characterized in that 
at least one value of the length of the defined context identifier is 

reserved for an uncompressed data flow. 
30 14. A system as claimed in cl^im 12 or 13, in which system 

compression is arranged to be controlled by a convergence protocol layer of a 

mobile system, characterized in that 

the mobile system is an-anged, in response to exceeding the 

number of data packet connections allowed by the context identifier length, to 
35 re-define the parameters of a radio bearer so that the new value of the context 
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identifier length enables the compression of the header fields of all data 
packet connections. 

15. A system as claimed in claim 12 or 13, in which system 
compression is arranged to be controlled by the convergence protocol layer of 
5 themobilesystem.characterized inthat 

the convergence protocol layer is arranged, in response to 
exceeding the number of data packet connections allowed by the maximuhi 
value of the context identifier length, to define for the data packet connections 
several link-level connections to which the data packet connections are 
10 allocated. 
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